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Abstract 


Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as 
sequences of topological subpaths, called "segments". These segments are advertised by routing 
protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP 
topologies. 


This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address 
family in order to carry SR information via BGP. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 
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1. Introduction 


Segment Routing (SR) allows for a flexible definition of end-to-end paths by combining subpaths 
called "segments". A segment can represent any instruction: topological or service based. A 
segment can have a local semantic to an SR node or global semantic within a domain. Within IGP 
topologies, an SR path is encoded as a sequence of topological subpaths, called "IGP segments". 
These segments are advertised by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3). 


[RFC8402] defines the link-state IGP segments -- prefix, node, anycast, and adjacency segments. 
Prefix segments, by default, represent an ECMP-aware shortest-path to a prefix, as per the state 
of the IGP topology. Adjacency segments represent a hop over a specific adjacency between two 
nodes in the IGP. A prefix segment is typically a multi-hop path while an adjacency segment, in 
most of the cases, is a one-hop path. Node and anycast segments are variations of the prefix 
segment with their specific characteristics. 


When SR is enabled in an IGP domain, segments are advertised in the form of Segment 
Identifiers (SIDs). The IGP link-state routing protocols have been extended to advertise SIDs and 
other SR-related information. IGP extensions are described for: IS-IS [RFC8667], OSPFv2 
[RFC8665], and OSPFv3 [RFC8666]. Using these extensions, SR can be enabled within an IGP 
domain. 


SR allows advertisement of single or multi-hop paths. The flooding scope for the IGP extensions 
for SR is IGP area-wide. Consequently, the contents of a Link-State Database (LSDB) or a Traffic 
Engineering Database (TED) has the scope of an IGP area; therefore, by using the IGP alone, it is 
not enough to construct segments across multiple IGP area or Autonomous System (AS) 
boundaries. 


In order to address the need for applications that require topological visibility across IGP areas, 
Or even across ASes, the BGP-LS address family / subaddress family have been defined to allow 
BGP to carry link-state information. The BGP Network Layer Reachability Information (NLRI) 
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encoding format for BGP-LS and a new BGP Path Attribute called the "BGP-LS Attribute" are 
defined in [RFC7752]. The identifying key of each link-state object, namely a node, link, or prefix, 
is encoded in the NLRI, and the properties of the object are encoded in the BGP-LS Attribute. 
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Figure 1: Link-State Information Collection 


Figure 1 denotes a typical deployment scenario. In each IGP area, one or more nodes are 
configured with BGP-LS. These BGP speakers form an Internal BGP (IBGP) mesh by connecting to 
one or more route reflectors. This way, all BGP speakers (specifically the route reflectors) obtain 
link-state information from all IGP areas (and from other ASes from External BGP (EBGP) peers). 
An external component connects to the route reflector to obtain this information (perhaps 
moderated by a policy regarding what information is or isn't advertised to the external 
component) as described in [RFC7752]. 


This document describes extensions to BGP-LS to advertise the SR information. An external 
component (e.g., a controller) can collect SR information from across an SR domain (as described 
in [RFC8402]) and construct the end-to-end path (with its associated SIDs) that needs to be 
applied to an incoming packet to achieve the desired end-to-end forwarding. SR operates within 
a trusted domain consisting of a single AS or multiple ASes managed by the same administrative 
entity, e.g., within a single provider network. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 
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2. BGP-LS Extensions for Segment Routing 


This document defines SR extensions to BGP-LS and specifies the TLVs and sub-TLVs for 
advertising SR information within the BGP-LS Attribute. Sections 2.4 and 2.5 list the equivalent 
TLVs and sub-TLVs in the IS-IS, OSPFv2, and OSPFv3 protocols. 


BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a Link NLRI, or a Prefix 
NLRI, and it defines the TLVs that map link-state information to BGP-LS NLRI within the BGP-LS 
Attribute. This document adds additional BGP-LS Attribute TLVs in order to encode SR 
information. It does not introduce any changes to the encoding of the BGP-LS NLRIs. 


2.1. Node Attribute TLVs 
The following Node Attribute TLVs are defined: 


Type Description Section 

1161  SID/Label Section 2.1.1 
1034 SR Capabilities Section 2.1.2 
1035 SR Algorithm Section 2 13 
1036 SR Local Block Section 2.1.4 


1037 SRMS Preference Section 2.1.5 
Table 1: Node Attribute TLVs 


These TLVs should only be added to the BGP-LS Attribute associated with the Node NLRI that 
describes the IGP node that is originating the corresponding IGP TLV/sub-TLV described below. 
2.1.1. SID/Label TLV 


The SID/Label TLV is used as a sub-TLV by the SR Capabilities (Section 2.1.2) and Segment Routing 
Local Block (SRLB) (Section 2.1.4) TLVs. This information is derived from the protocol-specific 
advertisements. 


* IS-IS, as defined by the SID/Label Sub-TLV in Section 2.3 of [RFC8667]. 


e OSPFv2/OSPFv3, as defined by the SID/Label Sub-TLV in Section 2.1 of [RFC8665] and Section 
3.1 of [RFC8666]. 


The TLV has the following format: 
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0 1 2 3 

0123456789012345678901234567890801 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SID/Label (variable) // 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 2: SID/Label TLV Format 


Where: 


Type: 1161 


Length: Variable. Either 3 or 4 octets depending on whether the value is encoded as a label or as 
an index/SID. 


SID/Label: Ifthe length is set to 3, then the 20 rightmost bits represent a label (the total TLV size 
is 7), and the 4 leftmost bits are set to 0. If the length is set to 4, then the value represents a 32- 
bit SID (the total TLV size is 8). 


2.1.2. SR Capabilities TLV 


The SR Capabilities TLV is used in order to advertise the node's SR capabilities including its 
Segment Routing Global Base (SRGB) range(s). In the case of IS-IS, the capabilities also include the 
IPv4 and IPv6 support for the SR-MPLS forwarding plane. This information is derived from the 
protocol-specific advertisements. 


* IS-IS, as defined by the SR-Capabilities Sub-TLV in Section 3.1 of [RFC8667]. 


e OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in Section 3.2 of [RFC8665]. OSPFv3 
leverages the same TLV as defined for OSPFv2. 


The SR Capabilities TLV has the following format: 
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0 1 2 3 
@1234567890123 456789 61234567 89 6 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flags | Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Range Size 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
SID/Label Sub-TLV 1 Hil 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+—+—+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Range Size N 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SID/Label Sub-TLV N Un 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 3: SR Capabilities TLV Format 


Where: 


Type: 1034 
Length: Variable. The minimum length is 12 octets. 


Flags: 1 octet of flags as defined in Section 3.1 of [RFC8667] for IS-IS. The flags are not currently 
defined for OSPFv2 and OSPFv3 and MUST be set to 0 and ignored on receipt. 


Reserved: 1 octet that MUST be set to 0 and ignored on receipt. 


One or more entries, each of which have the following format: 


Range Size: 3 octets with a non-zero value indicating the number of labels in the range. 


SID/Label TLV: (as defined in Section 2.1.1) used as a sub-TLV, which encodes the first label 
in the range. Since the SID/Label TLV is used to indicate the first label of the SRGB range, 
only label encoding is valid under the SR Capabilities TLV. 


2.1.3. SR-Algorithm TLV 
The SR-Algorithm TLV is used in order to advertise the SR algorithms supported by the node. This 
information is derived from the protocol-specific advertisements. 


* IS-IS, as defined by the SR-Algorithm Sub-TLV in Section 3.2 of [RFC8667]. 


e OSPFv2/OSPFVv3, as defined by the SR-Algorithm TLV in Section 3.1 of [RFC8665]. OSPFv3 
leverages the same TLV as defined for OSPFv2. 
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The SR-Algorithm TLV has the following format: 


0 1 2 3 
9519243575525 08759294011 e 052697:580000019024924:5526:/7288050/1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Algorithm 1 | Algorithm... | Algorithm N | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 4: SR-Algorithm TLV Format 


Where: 


Type: 1035 
Length: Variable. The minimum length is 1 octet and the maximum can be 256. 
Algorithm: One or more fields of 1 octet each that identifies the algorithm. 


2.1.4. SR Local Block TLV 


The SRLB TLV contains the range(s) of labels the node has reserved for local SIDs. Local SIDs are 
used, e.g., in IGP (IS-IS, OSPF) for Adjacency SIDs and may also be allocated by components other 
than IGP protocols. As an example, an application or a controller may instruct a node to allocate 
a specific local SID. Therefore, in order for such applications or controllers to know the range of 
local SIDs available, the node is required to advertise its SRLB. 


This information is derived from the protocol-specific advertisements. 


* IS-IS, as defined by the SRLB Sub-TLV in Section 3.3 of [RFC8667]. 


e OSPFv2/OSPFv3, as defined by the SR Local Block TLV in Section 3.3 of [RFC8665]. OSPFv3 
leverages the same TLV as defined for OSPFv2. 


The SRLB TLV has the following format: 
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0 1 2 3 
8-1:2.3.4.5. 6 7.8.9 80 1.2 3.4.5.6. 7.8.9. 6123456789 6 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flags | Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Sub-Range Size 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
SID/Label Sub-TLV 1 Hil 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+—+—+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Sub-Range Size N 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SID/Label Sub-TLV N Un 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 5: SRLB TLV Format 


Where: 


Type: 1036 
Length: Variable. The minimum length is 12 octets. 


Flags: 1 octet of flags. The flags are as defined in Section 3.3 of [RFC8667] for IS-IS. The flags are 
not currently defined for OSPFv2 and OSPFv3 and MUST be set to 0 and ignored on receipt. 


Reserved: 1 octet that MUST be set to 0 and ignored on receipt. 


One or more entries corresponding to a sub-range(s), each of which have the following format: 


Range Size: 3-octet value indicating the number of labels in the range. 


SID/Label TLV: (as defined in Section 2.1.1) used as a sub-TLV, which encodes the first label 
in the sub-range. Since the SID/Label TLV is used to indicate the first label of the SRLB sub- 
range, only label encoding is valid under the SR Local Block TLV. 


2.1.5. SRMS Preference TLV 


The Segment Routing Mapping Server (SRMS) Preference TLV is used in order to associate a 
preference with SRMS advertisements from a particular source. [RFC8661] specifies the SRMS 
functionality along with the SRMS preference of the node advertising the SRMS Prefix-to-SID 
mapping ranges. 
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This information is derived from the protocol-specific advertisements. 


* IS-IS, as defined by the SRMS Preference Sub-TLV in Section 3.4 of [RFC8667]. 


e OSPFv2/OSPFv3, as defined by the SRMS Preference TLV in Section 3.4 of [RFC8665]. OSPFv3 
leverages the same TLV as defined for OSPFv2. 


The SRMS Preference TLV has the following format: 


0 1 2 3 
02345678902? 3 4567/8902? 3 4567890] 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Preference | 

+-+-+-+-+-+-+-+-+ 

Figure 6: SRMS Preference TLV Format 


Where: 


Type: 1037 
Length: 1 octet 


Preference: 1 octet carrying an unsigned 8-bit SRMS preference. 


2.2. Link Attribute TLVs 
The following Link Attribute TLVs are defined: 


Type Description Section 
1099  Adjacency SID TLV Section 2.2.1 
1100 LAN Adjacency SID TLV Section 2.2.2 


1172 L2 Bundle Member Attributes TLV Section 2.2.3 
Table 2: Link Attribute TLVs 
These TLVs should only be added to the BGP-LS Attribute associated with the Link NLRI that 
describes the link of the IGP node that is originating the corresponding IGP TLV/sub-TLV 
described below. 
2.2.1. Adjacency SID TLV 


The Adjacency SID TLV is used in order to advertise information related to an Adjacency SID. 
This information is derived from the Adj-SID Sub-TLV of IS-IS (Section 2.2.1 of [RFC8667]), OSPFv2 
(Section 6.1 of [RFC8665]), and OSPFv3 (Section 7.1 of [RFC8666]). 
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The Adjacency SID TLV has the following format: 


0 1 2 3 
9519223541555 08729292011528354052697:58005001102439412526:57282050/1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flags | Weight | Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SID/Label/Index (variable) // 


Figure 7: Adjacency SID TLV Format 


Where: 


Type: 1099 
Length: Variable. Either 7 or 8 octets depending on the label or index encoding of the SID. 


Flags: 1-octet value that should be set as: 


* IS-IS Adj-SID flags as defined in Section 2.2.1 of [RFC8667]. 
* OSPFv2 Adj-SID flags as defined in Section 6.1 of [RFC8665]. 
* OSPFv3 Adj-SID flags as defined in Section 7.1 of [RFC8666]. 


Weight: 1 octet carrying the weight used for load-balancing purposes. The use of weight is 
described in Section 3.4 of [RFC8402]. 


Reserved: 2 octets that MUST be set to 0 and ignored on receipt. 
SID/Index/Label: 
IS-IS: Label or index value as defined in Section 2.2.1 of [RFC8667]. 
OSPFv2: Labelorindex value as defined in Section 6.1 of [RFC8665]. 


OSPFv3: Label or index value as defined in Section 7.1 of [RFC8666]. 


The Flags and, as an extension, the SID/Index/Label fields of this TLV are interpreted according to 
the respective underlying IS-IS, OSPFv2, or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link 
NLRI is used to determine the underlying protocol specification for parsing these fields. 


2.2.2. LAN Adjacency SID TLV 


For a LAN, normally a node only announces its adjacency to the IS-IS pseudonode (or the 
equivalent OSPF Designated and Backup Designated Routers). The LAN Adjacency SID TLV allows 
a node to announce adjacencies to all other nodes attached to the LAN in a single instance of the 
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BGP-LS Link NLRI. Without this TLV, the corresponding BGP-LS Link NLRI would need to be 
originated for each additional adjacency in order to advertise the SR TLVs for these neighbor 
adjacencies. 


This information is derived from the LAN-Adj-SID Sub-TLV of IS-IS (Section 2.2.2 of [RFC8667]), 
the LAN Adj-SID Sub-TLV of OSPF v2 (Section 6.2 of [RFC8665]), and the LAN Adj-SID Sub-TLV of 
OSPFv3 (Section 7.2 of [RFC8666]). 


The LAN Adjacency SID TLV has the following format: 


0 1 2 3 
A E AS O T E E 253545567 T e E a A S 5 67 829805] 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flags | Weight | Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OSPF Neighbor ID / IS-IS System ID 

+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SID/Label/Index (variable) // 


Figure 8: LAN Adjacency SID TLV Format 


Where: 


Type: 1100 


Length: Variable. For IS-IS, it would be 13 or 14 octets depending on the label or index encoding 
of the SID. For OSPF, it would be 11 or 12 octets depending on the label or index encoding of 
the SID. 


Flags: 1-octet value that should be set as: 


* IS-IS LAN Adj-SID flags as defined in Section 2.2.2 of [RFC8667]. 
* OSPFv2 LAN Adj-SID flags as defined in Section 6.2 of [RFC8665]. 
* OSPFv3 LAN Adj-SID flags as defined in Section 7.2 of [RFC8666]. 


Weight: 1 octet carrying the weight used for load-balancing purposes. The use of weight is 
described in Section 3.4 of [RFC8402]. 


Reserved: 2 octets that MUST be set to 0 and ignored on receipt. 
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Neighbor ID: 6 octets for IS-IS for the System ID, and 4 octets for OSPF for the OSPF Router-ID of 
the neighbor. 


SID/Index/Label: 


IS-IS: Label or index value as defined in Section 2.2.2 of [RFC8667]. 
OSPFv2: Label or index value as defined in Section 6.2 of [RFC8665]. 


OSPFv3: Label or index value as defined in Section 7.2 of [RFC8666]. 


The Neighbor ID, Flags, and, as an extension, the SID/Index/Label fields of this TLV are 
interpreted according to the respective underlying IS-IS, OSPFv2, or OSPFv3 protocol. The 
Protocol-ID of the BGP-LS Link NLRI is used to determine the underlying protocol specification 
for parsing these fields. 


2.2.3. L2 Bundle Member Attributes TLV 


The L2 Bundle Member Attributes TLV identifies an L2 Bundle Member link, which in turn is 
associated with a parent L3 link. The L3 link is described by the Link NLRI defined in [RFC7752], 
and the L2 Bundle Member Attributes TLV is associated with the Link NLRI. The TLV MAY include 
sub-TLVs that describe attributes associated with the bundle member. The identified bundle 
member represents a unidirectional path from the originating router to the neighbor specified in 
the parent L3 link. Multiple L2 Bundle Member Attributes TLVs MAY be associated with a Link 
NLRI. 


This information is derived from L2 Bundle Member Attributes TLV of IS-IS (Section 2 of 
[RFC8668]). The equivalent functionality has not been specified as yet for OSPF. 


The L2 Bundle Member Attributes TLV has the following format: 


0 1 2 3 
01234567890123 456789012345p7890]1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| L2 Bundle Member Descriptor 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Link Attribute Sub-TLVs(variable) // 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 9: L2 Bundle Member Attributes TLV Format 


Where: 


Type: 1172 
Length: Variable. 
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L2 Bundle Member Descriptor: 4-octet field that carries a link-local identifier as defined in 


[RFC4202]. 


Link attributes for L2 Bundle Member links are advertised as sub-TLVs of the L2 Bundle Member 
Attributes TLV. The sub-TLVs are identical to existing BGP-LS TLVs as identified in the table 


below. 


TLV Code Point Description 


1088 Administrative group (color) 

1089 Maximum link bandwidth 

1090 Max. reservable link bandwidth 

1091 Unreserved bandwidth 

1092 TE default metric 

1093 Link protection type 

1099 Adjacency Segment Identifier (Adj-SID) TLV 
1100 LAN Adjacency Segment Identifier (Adj-SID) TLV 
1114 Unidirectional link delay 

1115 Min/Max Unidirectional link delay 

1116 Unidirectional Delay Variation 

1117 Unidirectional Link Loss 

1118 Unidirectional residual bandwidth 

1119 Unidirectional available bandwidth 

1120 Unidirectional Utilized Bandwidth 


Reference Document 
[RFC7752] 
[RFC7752] 
[RFC7752] 
[RFC7752] 
[RFC7752] 
[RFC7752] 
Section 2.2.1 
Section 2.2.2 
[RFC8571] 
[RFC8571] 
[RFC8571] 
[RFC8571] 
[RFC8571] 
[RFC8571] 


[RFC8571] 


Table 3: BGP-LS Attribute TLVs are also used as sub-TLVs of the L2 Bundle Member Attributes TLV 


2.3. Prefix Attribute TLVs 
The following Prefix Attribute TLVs are defined: 


Type Description Section 

1158 Prefix-SID Section 2.3.1 

1159 Range Section 2.3.5 
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Type Description Section 
1170 Prefix Attribute Flags Section 2.3.2 
1171 Source Router Identifier Section 2.3.3 


1174 Source OSPF Router-ID Section 2.3.4 
Table 4: Prefix Attribute TLVs 


These TLVs should only be added to the BGP-LS Attribute associated with the Prefix NLRI that 
describes the prefix of the IGP node that is originating the corresponding IGP TLV/sub-TLV 
described below. 


2.3.1. Prefix-SID TLV 


The Prefix-SID TLV is used in order to advertise information related to a Prefix-SID. This 
information is derived from the Prefix-SID Sub-TLV of IS-IS (Section 2.1 of [RFC8667]), the Prefix- 
SID Sub-TLV of OSPFv2 (Section 5 of [RFC8665]), and the Prefix-SID Sub-TLV of OSPFv3 (Section 6 
of [RFC8666]). 


The Prefix-SID TLV has the following format: 


0 1 2 3 
9051052131541559627482940110203049554697228599011520324:2526:57282050 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flags | Algorithm | Reserved 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SID/Index/Label (variable) // 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 10: Prefix-SID TLV Format 


Where: 


Type: 1158 
Length: Variable. 7 or 8 octets depending on the label or index encoding of the SID. 


Flags: 1-octet value that should be set as: 


* IS-IS Prefix-SID flags as defined in Section 2.1.1 of [RFC8667]. 
e OSPFv2 Prefix-SID flags as defined in Section 5 of [RFC8665]. 
* OSPFv3 Prefix-SID flags as defined in Section 6 of [RFC8665]. 


Algorithm: 1-octet value identifies the algorithm. The semantics of the algorithm are described 
in Section 3.1.1 of [RFC8402]. 
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Reserved: 2 octets that MUST be set to 0 and ignored on receipt. 


SID/Index/Label: 


IS-IS: Label or index value as defined in Section 2.1 of [RFC8667]. 
OSPFv2: Label or index value as defined in Section 5 of [RFC8665]. 


OSPFv3: Label or index value as defined in Section 6 of [RFC8666]. 


The Flags and, as an extension, the SID/Index/Label fields of this TLV are interpreted according to 
the respective underlying IS-IS, OSPFv2, or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix 
NLRI is used to determine the underlying protocol specification for parsing these fields. 


2.3.2. Prefix Attribute Flags TLV 


The Prefix Attribute Flags TLV carries IPv4/IPv6 prefix attribute flags information. These flags are 
defined for OSPFv2 in Section 2.1 of [RFC7684], OSPFv3 in Appendix A.4.1.1 of [RFC5340], and IS- 
IS in Section 2.1 of [RFC7794]. 


The Prefix Attribute Flags TLV has the following format: 


0 1 2 3 
0123456789012345678901234567809080$81 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flags (variable) // 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 11: Prefix Attribute Flags TLV Format 


Where: 


Type: 1170 
Length: Variable. 


Flags: a [variable-length Flag field (according to the Length field). Flags are routing protocol 
specific and are to be set as below: 


* IS-IS flags correspond to the IPv4/IPv6 Extended Reachability Attribute Flags defined in 
Section 2.1 of [RFC7794]. In the case of the X-flag when associated with IPv6 prefix 
reachability, the setting corresponds to the setting of the X-flag in the fixed format of IS-IS 
TLVs 236 [RFC5308] and 237 [RFC5120]. 

* OSPFv2 flags correspond to the Flags field of the OSPFv2 Extended Prefix TLV defined in 
Section 2.1 of [RFC7684]. 

* OSPFv3 flags map to the Prefix Options field defined in Appendix A.4.1.1 of [RFC5340] and 
extended in Section 3.1 of [RFC8362]. 
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The Flags field of this TLV is interpreted according to the respective underlying IS-IS, OSPFv2, or 
OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI is used to determine the underlying 
protocol specification for parsing this field. 


2.3.3. Source Router Identifier TLV 


The Source Router Identifier TLV contains the IPv4 or IPv6 Router Identifier of the originator of 
the prefix. For the IS-IS protocol, this is derived from the IPv4/IPv6 Source Router ID Sub-TLV as 
defined in Section 2.2 of [RFC7794]. For the OSPF protocol, this is derived from the Prefix Source 
Router Address Sub-TLV as defined in Section 2.2 of [RFC9084]. 


The Source Router Identifier TLV has the following format: 


0 1 2 3 
0510293549526 9 7480020118203 042451697:81950/8] 02436408526 5/2 889802 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 4- or 16-octet Router Identifier Jr 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 12: Source Router Identifier TLV Format 


Where: 


Type: 1171 
Length: Variable. 4 or 16 octets for the IPv4 or IPv6 prefix, respectively. 


Router-ID: the IPv4 or IPv6 Router-ID in the case of IS-IS, and the IPv4 or IPv6 Router Address in 
the case of OSPF. 


2.3.4. Source OSPF Router-ID TLV 


The Source OSPF Router-ID TLV is applicable only for the OSPF protocol and contains the OSPF 
Router-ID of the originator of the prefix. It is derived from the Prefix Source OSPF Router-ID Sub- 
TLV as defined in Section 2.1 of [RFC9084]. 


The Source OSPF Router-ID TLV has the following format: 


0 1 2 3 

@12 34567896 123 4556789 61234567 3°9 6 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 4-octet OSPF Router-ID iif 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 13: Source OSPF Router-ID TLV Format 
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Where: 


Type: 1174 
Length: 4 octets 


OSPF Router-ID: the OSPF Router-ID of the node originating the prefix. 


2.3.5. Range TLV 


The Range TLV is used in order to advertise a range of prefix-to-SID mappings as part of the 
SRMS functionality [RFC8661], as defined in the respective underlying IGP SR extensions: Section 
4 of [RFC8665], Section 5 of [RFC8666], and Section 2.4 of [RFC8667]. The information advertised 
in the Range TLV is derived from the SID/Label Binding TLV in the case of IS-IS and the OSPFv2/ 
OSPFv3 Extended Prefix Range TLV in the case of OSPFv2/OSPFv3. 


A Prefix NLRI, that has been advertised with a Range TLV, is considered a normal routing prefix 
(i.e., prefix reachability) only when there is also an IGP metric TLV (TLV 1095) associated it. 
Otherwise, it is considered only as the first prefix in the range for prefix-to-SID mapping 
advertisement. 


The format of the Range TLV is as follows: 


0 1 2 3 
012345678901234567890123456780901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flags | Reserved | Range Size | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
l sub-TLVs 7 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 14: Range TLV Format 


Where: 


Type: 1159 
Length: Variable. 11 or 12 octets depending on the label or index encoding of the SID. 


Flags: 1-octet value that should be set as: 


* IS-IS SID/Label Binding TLV flags as defined in Section 2.4.1 of [RFC8667]. 
* OSPFv2 OSPF Extended Prefix Range TLV flags as defined in Section 4 of [RFC8665]. 
* OSPFv3 Extended Prefix Range TLV flags as defined in Section 5 of [RFC8666]. 


Reserved: 1 octet that MUST be set to 0 and ignored on receipt. 
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Range Size: 2 octets that carry the number of prefixes that are covered by the advertisement. 


The Flags field of this TLV is interpreted according to the respective underlying IS-IS, OSPFv2, or 
OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI is used to determine the underlying 
protocol specification for parsing this field. 


The prefix-to-SID mappings are advertised using sub-TLVs as below: 


IS-IS: 
SID/Label Range TLV 
Prefix-SID Sub-TLV 


OSPFv2/OSPFv3: 
OSPFv2/OSPFv3 Extended Prefix Range TLV 
Prefix-SID Sub-TLV 


BGP-LS: 
Range TLV 
Prefix-SID TLV (used as a sub-TLV in this context) 


The prefix-to-SID mapping information for the BGP-LS Prefix-SID TLV (used as a sub-TLV in this 
context) is encoded as described in Section 2.3.1. 


2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs 


This section illustrates the IS-IS Segment Routing Extensions TLVs and sub-TLVs mapped to the 
ones defined in this document. 


For each BGP-LS TLV, the following table illustrates its equivalence in IS-IS. 


Description IS-IS TLV/sub-TLV Reference 
SR Capabilities SR-Capabilities Sub-TLV (2) [RFC8667] 
SR Algorithm SR-Algorithm Sub-TLV (19) [RFC8667] 
SR Local Block SR Local Block Sub-TLV (22) [RFC8667] 
SRMS Preference SRMS Preference Sub-TLV (19) [RFC8667] 
Adjacency SID Adj-SID Sub-TLV (31) [RFC8667] 
LAN Adjacency SID LAN-Adj-SID Sub-TLV (32) [RFC8667] 
Prefix-SID Prefix-SID Sub-TLV (3) [RFC8667] 
Range SID/Label Binding TLV (149) [RFC8667] 
SID/Label SID/Label Sub-TLV (1) [RFC8667] 
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Description IS-IS TLV/sub-TLV Reference 
Prefix Attribute Flags Prefix Attribute Flags Sub-TLV (4) [RFC7794] 
Source Router Identifier IPv4/IPv6 Source Router ID Sub-TLV (11/12)  [RFC7794] 
L2 Bundle Member Attributes L2 Bundle Member Attributes TLV (25) [RFC8668] 


Table 5: IS-IS Segment Routing Extensions TLVs/Sub-TLVs 


2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs 


This section illustrates the OSPFv2 and OSPFv3 Segment Routing Extensions TLVs and sub-TLVs 
mapped to the ones defined in this document. 


For each BGP-LS TLV, the following tables illustrate its equivalence in OSPFv2 and OSPFv3. 


Description OSPFv2 TLV/sub-TLV Reference 
SR Capabilities SID/Label Range TLV (9) [RFC8665] 
SR Algorithm SR-Algorithm TLV (8) [RFC8665] 
SR Local Block SR Local Block TLV (14) [RFC8665] 
SRMS Preference SRMS Preference TLV (15) [RFC8665] 
Adjacency SID Adj-SID Sub-TLV (2) [RFC8665] 
LAN Adjacency SID LAN Adj-SID Sub-TLV (3) [RFC8665] 
Prefix-SID Prefix-SID Sub-TLV (2) [RFC8665] 
Range OSPF Extended Prefix Range TLV (2) [RFC8665] 
SID/Label SID/Label Sub-TLV (1) [RFC8665] 
Prefix Attribute Flags Flags of OSPFv2 Extended Prefix TLV (1) [RFC7684] 


Source Router Identifier Prefix Source Router Address Sub-TLV (5) [RFC9084] 


Source OSPF Router-ID Prefix Source OSPF Router-ID Sub-TLV (4)  [RFC9084] 
Table 6: OSPFv2 Segment Routing Extensions TLVs/Sub-TLVs 


Description OSPFv3 TLV/sub-TLV Reference 
SR Capabilities SID/Label Range TLV (9) [RFC8665] 
SR Algorithm SR-Algorithm TLV (8) [RFC8665] 
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SR Local Block 


SRMS Preference 


Adjacency SID 


LAN Adjacency SID 


Prefix-SID 
Range 


SID/Label 


Prefix Attribute Flags 


Source OSPF Router Identifier 


Source OSPF Router-ID 


OSPFv3 TLV/sub-TLV 

SR Local Block TLV (14) 
SRMS Preference TLV (15) 
Adj-SID Sub-TLV (5) 

LAN Adj-SID Sub-TLV (6) 


Prefix-SID Sub-TLV (4) 


OSPFv3 Extended Prefix Range TLV (9) 


SID/Label Sub-TLV (7) 


Prefix Option Fields of Prefix TLV types 3,5,6 


Prefix Source Router Address Sub-TLV (28) 


Prefix Source OSPF Router-ID Sub-TLV (27) 
Table 7: OSPFv3 Segment Routing Extensions TLVs/Sub-TLVs 


3. IANA Considerations 


IANA has registered the following code points in the "BGP-LS Node Descriptor, Link Descriptor, 
Prefix Descriptor, and Attribute TLVs" registry under the "Border Gateway Protocol - Link State 
(BGP-LS) Parameter" registry based on Table 8. The column "IS-IS TLV/Sub-TLV" defined in the 

registry does not require any value and should be left empty. 


3.1. TLV/Sub-TLV Code Points Summary 


This section contains the global table of all TLVs/sub-TLVs defined in this document. 
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1034 


1035 


1036 


1037 


1099 


1100 


Description 

SR Capabilities 
SR Algorithm 

SR Local Block 
SRMS Preference 
Adjacency SID 


LAN Adjacency SID 


Standards Track 


Reference 


Section 2.1.2 


Section 2.1.3 


Section 2.1.4 


Section 2.1.5 


Section 2.2.1 


Section 2.2.2 


August 2021 


Reference 
[RFC8665] 
[RFC8665] 
[RFC8666] 
[RFC8666] 
[RFC8666] 
[RFC8666] 
[RFC8666] 
[RFC8362] 
[RFC9084] 


[RFC9084] 
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TLV Code Point Description Reference 
1158 Prefix-SID Section 2.3.1 
1159 Range Section 2.3.5 
1161 SID/Label Section 2.1.1 
1170 Prefix Attribute Flags Section 2.3.2 
T0571 Source Router Identifier Section 2.3.3 
1172 L2 Bundle Member Attributes Section 2.2.3 
1174 Source OSPF Router-ID Section 2.3.4 


Table 8: Summary of TLV/Sub-TLV Code Points 


4. Manageability Considerations 


This section is structured as recommended in [RFC5706]. 


The new protocol extensions introduced in this document augment the existing IGP topology 
information that is distributed via [RFC7752]. Procedures and protocol extensions defined in this 
document do not affect the BGP protocol operations and management other than as discussed in 
the Manageability Considerations section of [RFC7752]. Specifically, the malformed attribute tests 
for syntactic checks in the Fault Management section of [RFC7752] now encompass the new BGP- 
LS Attribute TLVs defined in this document. The semantic or content checking for the TLVs 
specified in this document and their association with the BGP-LS NLRI types or their BGP-LS 
Attribute is left to the consumer of the BGP-LS information (e.g., an application or a controller) 
and not the BGP protocol. 


A consumer of the BGP-LS information retrieves this information over a BGP-LS session (refer to 
Sections 1 and 2 of [RFC7752]). The handling of semantic or content errors by the consumer 
would be dictated by the nature of its application usage and hence is beyond the scope of this 
document. 


This document only introduces new Attribute TLVs, and any syntactic error in them would result 
in the BGP-LS Attribute being discarded with an error log. The SR information introduced in BGP- 
LS by this specification may be used by BGP-LS consumer applications like an SR Path 
Computation Engine (PCE) to learn the SR capabilities of the nodes in the topology and the 
mapping of SR segments to those nodes. This can enable the SR PCE to perform path 
computations based on SR for traffic engineering use cases and to steer traffic on paths different 
from the underlying IGP-based distributed best-path computation. Errors in the encoding or 
decoding of the SR information may result in the unavailability of such information to the SR PCE 
or incorrect information being made available to it. This may result in the SR PCE not being able 
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to perform the desired SR-based optimization functionality or to perform it in an unexpected or 
inconsistent manner. The handling of such errors by applications like SR PCE may be 
implementation specific and out of scope of this document. 


The extensions, specified in this document, do not introduce any new configuration or 
monitoring aspects in BGP or BGP-LS other than as discussed in [RFC7752]. The manageability 
aspects of the underlying SR features are covered by [RFC9020], [ISIS-SR-YANG], and [OSPF-SR- 
YANG]. 


5. Security Considerations 


The new protocol extensions introduced in this document augment the existing IGP topology 
information that is distributed via [RFC7752]. The advertisement of the SR link attribute 
information defined in this document presents similar risk as associated with the existing set of 
link attribute information as described in [RFC7752]. The Security Considerations section of 
[RFC7752] also applies to these extensions. The procedures and new TLVs defined in this 
document, by themselves, do not affect the BGP-LS security model discussed in [RFC7752]. 


The TLVs introduced in this document are used to propagate IGP-defined information (see 
[RFC8665], [RFC8666], and [RFC8667]). These TLVs represent the SR information associated with 
the IGP node, link, and prefix. The IGP instances originating these TLVs are assumed to support 
all the required security and authentication mechanisms (as described in [RFC8665], [RFC8666], 
and [RFC8667] in order to prevent any security issue when propagating the TLVs into BGP-LS. 


BGP-LS SR extensions enable traffic engineering use cases within the SR domain. SR operates 
within a trusted domain [RFC8402], and its security considerations also apply to BGP-LS sessions 
when carrying SR information. The SR traffic engineering policies using the SIDs advertised via 
BGP-LS are expected to be used entirely within this trusted SR domain (e.g., between multiple 
ASes/domains within a single provider network). Therefore, precaution is necessary to ensure 
that the link-state information (including SR information) advertised via BGP-LS sessions is 
limited to consumers in a secure manner within this trusted SR domain. BGP peering sessions for 
address families other than link state may be set up to routers outside the SR domain. The 
isolation of BGP-LS peering sessions is recommended to ensure that BGP-LS topology information 
(including the newly added SR information) is not advertised to an external BGP peering session 
outside the SR domain. 
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